Internet Info 1993/Internet Info CD-ROM (Walnut Creek) (1993).iso/inet/ietf/x400ops/x400ops-minutes-91jul.txt

Text File | 1993-02-17 | 31.3 KB | 719 lines

CURRENT_MEETING_REPORT_

Reported by Kevin Jordan/CDC

X400OPS Minutes

Welcome.

There were no additional comments against the St.  Louis meeting
Minutes.

The IETF X.400 Operations Working Group.

Alf Hansen and Rob Hagens are now Co-Chairs of the Working Group.  Alf
is returning home to Norway.  The old X.400 Working Group has been
merged with the X.400 Operations Working Group.  The most significant
work item completed by the old X.400 Working Group was an RFC describing
how to use DNS to store RFC1148 mapping information.  The status of this
RFC is that it is awaiting proof of concept through implementation.

Because the two X.400 Working Groups have merged, the Working Group
Charter will be updated to add a new goal:  the Working Group will
attempt to drive X.400 deployment in the Internet.

The X.400 Operational Requirements RFC was originally scheduled to be
available for comment in July.  This schedule needs to be revised
because a lot of work is left to be done (especially considering the
comments and resolutions discussed in Atlanta).

The following questions were asked:  ``Is XNREN a U.S. or an
international PRMD? How would an organization outside of the U.S.
join?''

Alf attempted to provide an answer by indicating that the IETF should
find a way to register XNREN as a PRMD in each country.  It is not clear
exactly how this would be accomplished, but extensive cooperation from
the international Internet community is required.

Status of the document, ``An X.400 Internet Strategy''.

Work on the document continues.  It is slightly behind schedule.

Roundtable presentation of current X.400 service status.

At this point, the Working Group members who are currently operating
X.400 services described the status of those services:


SURFNet          (Netherlands) The SURFNet operations team is currently
                 working to improve the robustness of the service by
                 providing live backups for key service elements, i.e.,
                 redundant WEP's and RFC987 gateways.
                 An international agreement is needed on how to define

                                   1





                 backup WEP's with associated priorities (like the MX
                 concept in SMTP and DNS) so that MTA's can try
                 alternate backup connections.  Note:  RARE WG1 has
                 begun work on this concept.
                 SURFnet currently serves about 800 active X.400 users,
                 and the number of users is growing rapidly.
                 X.400 implementations for Mac's and PC's are being
                 evaluated, as are X.400 gateway products for Mac/PC
                 LANS (e.g.  cc:Mail, Banyan).
                 SURFNet Observation:  Most currently available X.400
                 user interfaces are still quite primitive.
COSINE           Cooperation for OSI Networking in Europe.  COSINE is a
                 program funded by a number of European Governments
                 (basically the European Community plus European Free
                 Trade Association countries) plus the Commission of
                 European Communities.  Broadly, the mission is to
                 provide OSI based services for the European research
                 community.  The prime contractor entrusted to fulfill
                 this mission is RARE.
                 COSINE includes:
                 RARE Reseaux Associe pour la Recherche Europeenne
                 EEMA European Electronic Mail Association EEMA is an
                 association whose membership is comprised of a number
                 of European organizations, some very large (almost
                 exclusively non R&D based).  They come together to
                 discuss issues related to electronic messaging in
                 Europe.  RARE/COSINE decided to become a member of
                 EEMA, with a view to feed back the experiences learned
                 by the RARE/COSINE MHS services into industry, (i.e.,
                 act as an experience pool), To make the views of the
                 COSINE user community felt in this forum.
                 Y-Net OSI Services for ESPRIT researchers Y-NET is a
                 project with its primary aim being to provide OSI based
                 services to European Community SMEs (Small and Medium
                 sized Enterprises) involved in the ESPRIT program.
                 COSINE MHS is mandated to coordinate with Y-NET. An aim
                 of COSINE MHS is to provide a seamless service between
                 the Y-NET and COSINE MHS user communities.
                 EurOpen
COSINE-MHS       is a project which was chartered to drive deployment of
                 X.400 in the European research community.  Transport
                 service stacks include:  TP0/CONS/X.25/LAPB,
                 TP0/CONS/X.25/LLC2, TP0/RFC1006/TCP, TP4/CLNS.
                 X.400 '84 is used universally within the COSINE-MHS
                 community.  Some organizations are experimenting with
                 X.400 '88, but there is no wide spread use of '88 yet.
                 The European public service providers (the PTT's) offer
                 '84 service only.
                 The COSINE-MHS project is currently comprised of
                 between 20 and 25 WEP's.  Connectivity between WEP's is

                                   2





                 not universal.  Even with this relatively small number
                 of WEP's, the amount of static configuration
                 information which must be maintained and coordinated is
                 approaching an unmanageable level.  There is a very
                 urgent need for dynamic configuration management via
                 X.500 directory services and/or DNS.
                 Some countries consider COSINE-MHS to be an operational
                 service, and some countries consider it to be a pilot
                 service.  Consequently, varying degrees of support and
                 administration are provided.
                 A universal gateway service, COSINE-GW, is being
                 implemented in Trieste, Italy.  This gateway will
                 provide connectivity between practically all commonly
                 used electronic mail networks including:  X.400,
                 RFC822, BITNet/EARN, HEPNET (Mail-11), and SPAN
                 (Mail-11).  Connectivity with XNREN is also being
                 implemented.
SWITCH           (Switzerland) SWITCH has one main WEP which provides
                 access to the Swiss research community.  This main WEP
                 has ADMD connectivity.  SWITCH serves about 8000 real
                 end users.  About 50 academic and research
                 organizations are connected.  Five commercial
                 organizations are connected.  Commercial organizations
                 must connect as independent PRMD's.
UK               Two main X.400 services operate within the UK
                 academic/research community:  EAN and MHS-Relay
                 (PP-based).  Connectivity with 3 ADMD's is provided.
                 Most UK sites are operating X.400 '84 services, but 3
                 sites are experimenting with '88 internally.
GARR             (Italy) GARR is registered as an official Italian ADMD,
                 but it primarily services the academic/research
                 community and is not a public service provider.  GARR
                 is connected with 2 public service ADMD's in Italy.
                 GARR's potential user community numbers between 10,000
                 and 100,000 people.
                 GARR provides one principal access point (WEP) to
                 COSINE. Backup WEP's are planned, pending international
                 agreements on how to define and configure prioritized
                 alternative MTA's for X.400 destinations.
                 X.400 '88 deployment is being considered, but GARR
                 currently has no time table in place for deployment.
ARC              (NASA-Ames Research Center) The primary WEP for ARC was
                 recently transferred from a microVAX to a SUN. While
                 the transfer was in progress, connectivity to ARC was
                 lost.  ARC is working on connectivity to SPRINT. A fax
                 gateway is planned.  ARC is considered an experimental
                 rather than an operational X.400 mail service.
CDC              Control Data operates its on PRMD named CDC. Control
                 Data has a connection to XNREN via Internet and is also

                                   3





                 a subscriber to ADMD ATTMail.  CDC is connected to
                 ATTMail via AT&T's public X.25 network named Accunet.
                 Internally, CDC operates an X.400 network which
                 currently interconnects 3 principal corporate
                 locations:  Arden Hills, Minnesota; Bloomington,
                 Minnesota; and Santa Clara, California.  It is
                 estimated that well over 1000 X.400 messages per day
                 are exchanged between and within these three locations.
                 The number of users served is in the hundreds.
                 CDC has produced two main X.400 implementations.  These
                 are marketed as Control Data products, and they are
                 also used very heavily within the company.  One of the
                 implementations, named MHS/4000, runs on the Control
                 Data 4000 series of computer systems (based on the MIPS
                 RISC chipset and running CDC's variant of UNIX named
                 EP/IX). The other implementation, named Mail/VE, runs
                 on the Control Data CYBER 180 series of mainframe
                 computer systems under the NOS/VE operating system.
                 Several of CDC's customers in Europe (particularly
                 Germany) are taking advantage of CDC's connection with
                 XNREN. They are able to exchange true X.400 mail
                 between their sites and Customer Support analysts at
                 CDC in Minnesota.  One of the customers even sends
                 periodic X.400 ``pings'' from his X.400 mailbox in
                 Germany to an autoforwarding mailbox at CDC in
                 Minnesota.  The autoforwarding mailbox forwards mail
                 back to his mailbox in Germany.  This allows him to
                 verify that the international X.400 network is fully
                 operational (between Germany and Minnesota at least).
                 CDC has implemented an X.400-based fax gateway and is
                 currently using it internally.  This gateway will be
                 released as a CDC product in the Fall.  The gateway can
                 accept messages containing IA5-Text, Unidentified (aka
                 Bilateral), and G3-Fax body parts.  IA5-Text body parts
                 can contain plain text, PostScript, uuencoded digital
                 imagery, and digital imagery encoded using Macintosh
                 BinHex format.  TIFF, GIF, PICT, MacPaint, XBM, XWD,
                 PBM, PPM, PGM, and Sun Raster digital image formats are
                 recognized.  Unidentified type body parts may also
                 contain any of these formats (without having to be
                 uuencoded or BinHex encoded).  The gateway provides
                 access controls and accounting, it honors deferred
                 delivery requests, and it generates X.400 delivery
                 reports.  It also allows the network administrator to
                 design customized cover sheets.  It can receive as well
                 as send faxes, and, of course, it can serve non-X.400
                 users across an RFC987 gateway.

ESNet            ESNet is implementing X.400 connectivity with XNREN.
                 Internally, ESNet is providing pilot services to energy
                 research labs.  As ESNet must meet U.S. GOSIP
                 requirements, the internal ESNet OSI backbone will be

                                   4





                 based on TP4/CLNS. The potential ESNet user community
                 is about 4500 people.
CDNNet           (Canada) CDNNet is topologically organized as a star.
                 A WEP and RFC987 gateway are located at the center of
                 the star.  About 40 organizations, Canada-wide, are
                 connected to CDNNet.  CDNNet has connections with XNREN
                 and Envoy.  CDNNet is considering becoming an ADMD.
                 CDNNet participates in support of EAN. The number of
                 X.400 end users served by CDNNet numbers in the
                 thousands.
MITRE            MITRE's X.400 service is '84 based.  MITRE's X.400
                 network has two main relays.  One is located in
                 Bedford, Massachusetts, and the other is located in
                 Washington, D.C. Routing is hierarchical and
                 concentrated at the two main relays.  Departmental
                 MTA's are configured with simple default routes to the
                 central relays.
                 MITRE's X.400 service is confined within the
                 corporation.  MITRE does not yet exchange X.400 mail
                 with other organizations because MITRE has not yet
                 integrated the OSI protocol suite into its security
                 perimeter mechanisms.
                 The MITRE X.400 service is currently operating as a
                 mail backbone transport service only.  X.400 mail is
                 not yet exchanged with end users directly, i.e.  X.400
                 user agents have not been deployed.
                 X.500 (Quipu) is being used for address lookup and
                 distribution list expansion.  The principal user agent
                 in use is MH 6.7 with the enhancements that support
                 X.500.
                 MITRE's current view of OSI: ``It's tough to show the
                 added value of OSI at this time.''  OSI products are
                 immature.  GOSIP is incomplete.  It requires only
                 IA5-Text support in X.400 body parts, it does not
                 require X.500, and it does require any sort of network
                 management support.  The standards are incomplete.  For
                 example, the standards do not specify standard textual
                 representations for host names or email addresses.
XNREN            X.400 traffic passing through the main XNREN relay
                 steadily increases, but it is still relatively light.
                 In June, between 7000 and 8000 X.400 messages were
                 processed.  Most traffic originates from X.400 and is
                 destined for SMTP users.
PP               (release status) Steve Hardcastle-Kille provided the
                 following information about forthcoming releases of PP:
                 A beta release of PP was distributed very recently.  PP
                 6.0 is currently scheduled for general release in
                 September or October.  PP 6.0 will include a fax
                 channel.  At the present time, the fax channel works in

                                   5





                 the outbound direction only, but inbound should be
                 working soon.  In addition, the fax channel is
                 currently implemented to interface with a fax modem
                 which is not currently sold in the U.S. A Mail-11
                 channel will become available.  88->84 downgrading will
                 be supported per Steve's draft RFC. The Domain table
                 has been revised to look like the O/R table.  An
                 implementation of Message Store and an X Window User
                 Agent will become available.  The X Window UA will
                 probably be released with PP 6.0, but its quality will
                 be VERY beta in that release.  It will be suitable for
                 experimentation, but not for end user usage.
                 The PP API will be published.  Note:  this API will not
                 be compatible with the X/Open API for X.400, and there
                 are currently no plans to implement an X/Open
                 conformant API for PP.



Review of draft RFC, ``Requirements for X.400 PRMD's Operating in the
Internet.''

The Working Group went through the draft RFC section by section,
discussing issues and resolving them.  One major outcome of the dialogue
is that the focus of the document has changed from being U.S.-centric to
being international in scope.


   o Status of this Memo:  It was pointed out that the format of this
     section may not follow the approved wording format for Internet
     RFC's.

   o Introduction:  It was suggested that this section does not really
     introduce the reason for the existence of the document.  It dives
     into technical details too quickly.  This section should provide
     answers to the following questions:

      -  What is the rationale for deploying X.400 on the Internet?
      -  How does X.400 deployment relate to the forthcoming
         enhancements to SMTP?
      -  Why is this document being written?


     One justification for deploying X.400 on the Internet is that there
     are a number of Internet-connected organizations which are
     beginning to operate internal X.400 services (in compliance with
     U.S. GOSIP), and it should be possible to use the Internet to
     interconnect these services.

     Among other things, the document should provide a boilerplate which
     describes how to connect an organization to the Internet X.400
     network.

                                   6





  After considerable discussion, the following conclusions were
  drawn:

   -  We probably need to produce a separate document which clearly
      lays out the rationale for deploying X.400 on the Internet.

   -  The document needs to be expanded such that it accommodates the
      international R&D community.  In particular, the document must
      accommodate both of the XNREN and RARE/COSINE communities.

   -  Our basic goal is to foster an international X.400 service for
      the Internet.


  Profiles

  The intent of the profile section was to document the upper layer
  X.400 profiles which must be supported by participating
  organizations.  It was agreed that the document should merely refer
  to other documents which define standardized inter/national
  profiles because, in practice, existing X.400 implementations are
  interoperable, and they conform to standardized inter/national
  profiles.

o Management Domains:  Given that the document will be revised to
  accommodate international requirements, and given that a variety of
  management domain schemes are already in use, this section should
  describe existing practices.  In particular, it should describe the
  existing variety of PRMD's and ADMD's and point out that management
  domain interconnection requirements will vary from one country to
  the next.

  Lower Layer Stack Incompatibilities

  Discussion of this section prompted a long and lively dialogue
  concerning what the definition of ``Internet'' truly is, whether it
  is still necessary to retain the I-WEP concept, and whether it
  should be a requirement that all I-WEP's and/or WEP's be capable of
  direct interconnection.  In the process of resolving these issues,
  it was pointed out that the IAB has revised the definition of
  ``Internet'' as follows:

      Internet is a multiprotocol community which shares a common
      name service.

  Given this definition, the Working Group produced the following
  proposals for the definition of ``Internet X.400 Service'' or
  ``Internet X.400 Community''.  The proposals were produced in the
  order indicated below, each was discussed thoroughly, and then a
  revised proposal (based on the discussion) was generated.


                                7





 -  p1:  The Internet X.400 Community consists of X.400 communities
    which are connected with X.400 to the international R&D X.400
    community without the assistance of a third party intermediate
    ADMD.

 -  p2:  The X.400 Internet includes all sites where you can send
    an X.400 e-mail and get a non/delivery report in response.

 -  p3:  An organization is a member of the X.400 Internet
    Community if it meets the connectivity requirements defined in
    this RFC.


These proposals made it clear that our basic goal is to use the
Internet as a vehicle for maximizing X.400 connectivity.  Given
that agreement was reached on this goal, it became obvious that we
should allow organizations to connect to the X.400 Internet using
any of the following three lower layer stacks:  TP0/RFC1006/TCP,
TP0/CONS, TP4/CLNS

Furthermore, it should not be a requirement that every MTA or PRMD
directly support all three stacks, but if a particular stack is not
directly supported by a PRMD, the PRMD will need to make bilateral
agreements with other PRMD(s) in order to assure that connectivity
from all stacks is available.

The final agreed definition of ``Internet X.400 Sevice'' became:

    The Internet X.400 Service includes all organizations
    meeting the international requirements described in
    RFCxxxx.

where RFCxxxx is an RFC which describes requirements for connecting
to the international Internet X.400 network.  As mentioned above,
the lower layer protocol stacks supported by the international
Internet X.400 network are:

    TP0/RFC1006/TCP, TP0/CONS, TP4/CLNS

Connection requirements include:

 -  An organization must support at least one of the above stacks.
 -  An organization must insure that it is reachable from all
    stacks.  An organization can achieve universal reachability by:

     * Directly supporting all stacks

     * Negotiating bilateral agreements with other organizations
       which share a common stack and which either:

         +Support a stack not common to both organizations, or

                              8





           +Are willing to relay mail to organizations which do
            support other stack(s)

      Editorial note:  The TP0/CONS stack should probably be
      subdivided into the following two stacks:  TP0/CONS/X.25/LLC2,
      TP0/CONS/X.25/LAPB. These two stacks qualify as TP0/CONS, but
      their link layer solutions prevent them from being
      interoperable, so they are effectively as different as TP0 and
      TP4.


  Having made the resolutions described above, it was agreed that all
  references to the term I-WEP should be changed to WEP. It was
  agreed that the I-WEP concept is no longer necessary.

  In conjunction with the decisions made above, new proposals were
  made for the structure of routing tables maintained for the X.400
  network.  Two tables, an MTA table and a Domain table, will be
  defined.  The MTA table will define the names of well known MTA's
  (WEP's) and their associated connection data including selector
  values, NSAP addresses, supported protocol stacks, and supported
  X.400 protocol version(s) (i.e., 1984, 1988, 1992, etc.).

  Each entry in the proposed Domain table will consist of an X.400
  address, followed by a list of MTA's which are willing to accept
  mail for the address or provide a relay service for it.  Each MTA
  name will be associated with a priority value.  Collectively, the
  list of MTA names make the address reachable from all protocol
  stacks.  In addition, the list may provide redundant paths to the
  address, so in this case, the priority value indicates the
  preferred path, or the preferred order in which alternative routes
  should be tried.  The format of a Domain table entry might look
  like:


           C=CH; ADMD=ARCOM; PRMD=SWITCH
            PRIO=1, MTANAME=switch.ch
            PRIO=2, MTANAME=relay.dbp.de
            PRIO=3, MTANAME=mhs-relay.cs.wisc.edu


  Architectural Principles
  This section will be removed as it is no longer required that all
  WEP's be directly interconnected.

o Description of PRMD policies:  All references to PRMD will be
  changed to MD (Management Domain).  This will allow ADMD's to
  operate within the Internet X.400 Service.

  X.400 address registration

  This section will be updated such that it supports the

                                9





specification of numeric country codes, ADMD names, and PRMD
identifiers.  Support of numeric identifiers is required by the
X.400 standards and implementors agreements.

The description of ``unique address'' will be softened.  The basic
requirement is that all originator addresses transmitted into the
Internet X.400 Service must be universally ``repliable''.  In
support of this requirement, the document will recommend that users
align their addresses with exactly one ADMD name in cases where
they have a choice of ADMD names.

It was pointed out that the requirement that organization names be
nationally unique is not justified.  Organization names must be
unique within the context of the subscribed PRMD or ADMD, but they
need not be nationally unique.  The document will be updated
accordingly.

The document will include a strong recommendation about the syntax
of PRMD, O, and OU names.  Specifically, such names should consist
of letters, digits, and hyphens only.  Also, a hyphen should
neither occur as the first nor the last character of a name, nor
should a name begin with a digit.

The document needs to contain information about officially
supported DDA's.  In particular, the supported DDA's should be
listed along with their required syntaxes and semantics.  The
document must indicate the DDA's for which support is mandatory.

The document should reference the forthcoming RFC which describes
'88->'84 downgrading, and it should indicate that support of that
RFC is mandatory for organizations connected to the Internet X.400
Service.


 -  An organization with no defined X.400 address space

    This section will be reworded such that it clarifies the fact
    that the address of an RFC987 gateway need not be precisely:
    C=US; ADMD= ; PRMD=Internet

    In particular, the country name C=US is not mandatory.  Each
    country is free to choose its own well known RFC987 gateway
    address.  For example:  C=CH; ADMD= ; PRMD=Internet


General comments/issues:


 -  The document should mention that issues concerning X.400 '88
    are, in general, left for further study.  This leaves a hook
    for future work.


                             10





      -  The document should reference a separate RFC which will
         describe the details of routing.  Section 4.3 of the current
         draft will be moved into the routing RFC.

      -  The ``6A'' concept described in the current draft needs to be
         revised such that it reflects the new international flavor of
         the document.

      -  X.400 network coordination and administration will need to be
         distributed between continents.  The X.400 Working Group, in
         concert with RARE/COSINE, will need to document administrative
         responsibilities and how they are divided between countries.

      -  We must determine how the commercial ADMD service providers
         relate to the Internet X.400 Service.


Use of distributed databases for routing/mapping purposes:

Claudio Allocchio presented his experiences in experimenting with DNS as
a solution for managing RFC987 routing/mapping tables.  First, Claudio
experimented with using PTR records for storing and managing mapping
tables.  His conclusion is that this is a reasonable short-term solution
(pending a better X.500-based solution).

Next, Claudio experimented with using MX records for managing X.400
routing information.  Again, he concluded that this is a reasonable
short-term solution.

Claudio is planning to implement and make generally available a portable
tool (written in C) which will allow an administrator to create the
standard RARE/COSINE routing/mapping tables from information stored in
DNS.

Kevin Jordan reminded the Working Group about the description he
distributed after the previous IETF meeting of CDC's use of X.500
directory services for managing X.400 routing/mapping information.
Kevin agreed to update this information and redistribute it to the
Working Group as a formal proposal.

X.400 84/88 downgrading:

Steve Hardcastle-Kille presented his draft RFC on '88->'84 downgrading.
He accepted comments from the Working Group and will make some minor
changes to the document.

Future issues:

No additional future issues were discussed.

Summary of conclusions and actions:

R. Hagens, A. Hansen.  The RFC authors will revise the document in

                                  11





accordance with the comments and conclusions generated at this meeting.
A new draft will be distributed prior to the next IETF meeting, no later
than November 11.

K. Jordan:  Kevin will update his previous white paper which described
CDC's usage of X.500 directory services in support of X.400
routing/mapping.  He will distribute the updated paper to the Working
Group as a formal proposal.

Kevin will also distribute a proposal for mapping X.400 O/R addresses to
X.500 distinguished names.  This mapping will allow X.500-based
routing/mapping information to be distributed easily across the
Internet, in a fashion similar to the way in which DNS information is
distributed.

C. Allocchio, E. Huizer, U. Eppenberger:  This team will distribute a
proposal for using DNS and/or FTP-based services for managing X.400
routing/mapping information.

S. Hardcastle-Kille:  Steve will update the '88->'84 downgrading RFC and
work with EWOS to make support of DD.COMMON well defined and mandatory.

P. Yee:  Peter will do some research into North American groups such as
EMA and NADF. He will discover what they are currently doing and
recommend a level of involvement for XNREN and/or the X.400 Working
Group.

Future meetings:

The next general IETF meeting is scheduled for November 18 - 22 in Santa
Fe, New Mexico.  The X.400 Operations Working Group will meet on
Wednesday and Thursday (November 23 and 24).  Also, if there is
sufficient interest, a BOF meeting may be organized.

Attendees

Claudio Allocchio        [e-mail]
William Biagi            [e-mail]
Peter Boos               [e-mail]
David Brent              [e-mail]
Vinton Cerf              [e-mail]
Henry Clark              [e-mail]
Curtis Cox               [e-mail]
Urs Eppenberger          eppen@v
Tony Genovese            [e-mail]
Arlene Getchell          [e-mail]
Robert Hagens            [e-mail]
Alf Hansen               [e-mail]
Steve Hardcastle-Kille   [e-mail]
Phillip Hasse            [e-mail]
Tim Howes                [e-mail].
Erik Huizer              [e-mail]
P. Allen Jensen          [e-mail]
Kevin Jordan             [e-mail]

                                  12





Jim Knowles              [e-mail]
Walter Lazear            [e-mail]
Jack Liu                 [e-mail]
Carl Malamud             [e-mail]
Joseph Malcom            [e-mail]
John McGuthry            [e-mail]
Harvey Shapiro           [e-mail]
Keld Simonsen            [e-mail]
Linda Winkler            [e-mail]
Russ Wright              [e-mail]
Peter Yee                [e-mail]



                                  13